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SPECIFICATION 



TO ALL WHOM IT MAY CONCERN: 

Be it known that we, Jeffrey Wayne McDonald and Christopher Edwin Warren, 
with residence and citizenship listed below, have invented the inventions described in the 
following specification entitled: 



Jeffrey Wayne McDonald residence: 46080 Fremont Blvd. 

Suite 148 

Fremont, CA 84538 
citizenship: United States of America 

Christopher Edwin Warren residence: 1012 N. Broadway, Apt. 403 

Kansas City, MO 64105 
citizenship: United States of America 



COMMUNICATING 
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COMMUNICATING 
BETWEEN A PROCESS AND A DESTINATION 



5 RELATED APPLICATIONS 

This application is a non-provisional application that claims the priority of prior 
provisional application serial number 60/158,262, entitled "METHOD AND 
APPARATUS FOR PROVIDING SOFTWARE FRAMEWORKS", filed October 7, 
1999, which is hereby incorporated by reference into this application. 
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jo 15 Not applicable 



C3 BACKGROUND OF THE INVENTION 

n 

m 1. FIELD OF THE INVENTION 

a,? s 

;!! The invention is related to the field of communication systems, and in particular, 

20 to a communication system for communicating between a process and a destination. 

2. DESCRIPTION OF THE PRIOR ART 

With the expansion of client-server applications, the need for improved message 
handling between computers continues to increase. The Internet, object oriented 

25 programming, and distributed processing have also contributed to the demand for better 
message handling. Application developers use messaging Application Program Interfaces 
(API) to handle the messaging. Thus, the application developers only need a high-level 
understanding of the messaging and rely on the messaging API to handle the lower level 
messaging functions of the operating system. 

30 One computer system called Tandem NonStop systems is a loosely-coupled 

parallel processor computer system designed to provide continuous availability for online 
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transaction processing. This Tandem system uses a Guardian operating system. One 
feature of the Tandem computers is the Transaction Management Facility (TMF). If an 
error occurs downstream, the Tandem's TMF allows the transaction to be rolled back. 
This eliminates the need for error recovery code at multiple points in the system. 
5 One messaging framework in the Tandem/Guardian environment is called 

NonStop Distributed Computing Environment (DCE). The NonStop DCE is a part of the 
Posix standard DCE. The NonStop DCE provides C functions for accessing services 
through a Remote Procedure Call (RPC) from one machine to a host machine. Another 
messaging framework is called Krypton. Krypton provides C functions for performing 
1 0 RMI similar to NonStop DCE. Krypton is available for Guardian, Unix, and Windows 
%n NT operating systems. Another messaging framework, Nonstop Domino (NS-DOM), 
fl provides C functions for invoking messaging services through the CORB A II API. One 
sp problem with the NonStop DCE, Krypton, and NS-DOM frameworks is the reliance on 
iff! Interface Description Language (DDL) to generate functions. The developer must compile 
^ y 1 5 the IDL scripts through an DDL compiler to generate messaging functions. 
M Another prior art system called RMS shell, which was developed by Sprint Inc., 

i H 

IIS handles messaging in Tandem computers. The RMS shell provides a messaging 
JlJ framework for creating client/server applications for the Tandem/Guardian environment, 
o The RMS shell handles only one transport protocol to communicate between processes. 
20 The RMS shell posts and receives wait messages by specifying a pointer and length of 
the messages. When an originating process sends a wait message, the originating process 
waits for a reply from the target process instead of continuing processing. One problem 
with the RMS shell is the RMS shell only handles one type of transport protocol, process 
to pathway. One disadvantage is the RMS shell code is in C, a low level non-object 
25 oriented programming language. Those skilled in the art understand the benefits of object 
oriented programming languages such as maintenance and the ease of using objects to 
build applications. Another problem with the RMS shell is that it only correctly handles 
wait messaging, so the originating process must wait for replies. The RMS shell 
incorrectly handles no-waited messaging causing the RMS shell to drop transactions 
30 during high volume messaging. Another problem with RMS shell is that it only handles 
one type of message format. 
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SUMMARY OF THE INVENTION 

The invention solves the above problems by communicating between a first 
process on a first computer and a destination on a second computer. The first computer 
5 receives destination information indicative of the destination from the first process. The 
first computer then determines a transport protocol for a message object based on the 
destination information. The first computer then generates the message object based on 
the destination information. The first computer receives message information indicative 
of a message to be transmitted from the first process to the destination. Finally, the first 
1 0 computer transmits the message information from the first process to the destination 

using the message object and the determined transport protocol. 

rn 

jf« In one embodiment, the destination is a second process on the second computer, 

= F where the transport protocol is a process to process communication. In another 
JH embodiment, the destination is a pathway to the second computer, where the transport 

%s * 1 5 protocol is a process to pathway communication. In still another embodiment, the 
destination is a socket on the second computer, where the transport protocol 
communication is a process to socket communication. 

The message information is a pointer and length of the message in one 
embodiment. In another embodiment, the message is waited or nowait. In another 
20 embodiment, the first computer checks for errors and calls an error service in response to 
the error. The first computer also generates an unique identifier for the message. 

One advantage of determining the transport protocol at run-time is the transport 
protocol may be determined by an environment variable. This allows the system 
administrator to alter the transport without recompiling or modifying code. Also, 
25 developers may add their own transport protocol without having to recompile application 
programs. 

Another advantage is multiple messages formats are supported in a standardized 
way with the actual data format hidden from the user. The developer writes a single piece 
of code capable of interacting with multiple servers using different message formats and 
30 transport protocols. 
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Error services is another advantage which allows developers to distinguish error 
conditions and separate error handling logic from normal business logic. The ability to 
invoke error services is considered as exception handling across processes. Error 
notification allows the developer to either retry the offending logic or propagate the error 
5 further upstream. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a communication system in an example of the 
invention. 

1 0 FIG. 2 is a flow chart of a communication system in an example of the invention. 

FIG. 3 is a block diagram of a communication system in a process to process 
communication in an example of the invention. 

FIG. 4 is a flow chart for a communication system for a process to process 
communication for transmitting a message in an example of the invention. 
1 5 FIG. 5 is a flow chart for a communication system for a process to process 

communication for receiving a message in an example of the invention. 

FIG. 6 is a block diagram of a communication system in a process to pathway 
communication in an example of the invention. 

FIG. 7 is a block diagram of a communication system in a process to socket 
20 communication in an example of the invention. 

FIG. 8 is a block diagram of a Message class in an example of the invention. 
FIG. 9 is a block diagram of a Service class and an Application class in an 
example of the invention. 

FIG. 10 is a block diagram of a Transport class in an example of the invention. 
25 FIG. 1 1 is a block diagram of a TransportProcess class, a TransportPathmon class, 

and a TransportSocket class in an example of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 
Communication System - FIG. 1-2 
30 FIG. 1 depicts a block diagram of a communication system 100 in an example of 

the invention. The communication system 100 comprises a first computer 110 and a 
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second computer 120. The first computer 110 comprises a first process 112 and a 
message object 1 14. The second computer 120 comprises a destination 122. The message 
object 1 14 is logically connected to the first process 112 and the destination 122. 

The first computer 110 could be any computer configured to (1) receive 
destination information indicative of the destination 122 from the first process 112, (2) 
determine a transport protocol for a message object 114 based on the destination 
information, (3) generate the message object 114 based on the destination information, 
(4) receive message information indicative of a message to be transmitted from the first 
process 112 to the destination 122, and (5) transmit the message information from the 
w 1 0 first process 1 12 to the destination 122 using the message object 114 and the determined 
transport protocol. The first process 112 could be any process or application running on 
the first computer 110. 
^ The destination 122 could be any target on the second computer 120 for 

CO communication with the first computer 110. Some examples of the destination 122 are a 

CO 

I 1 5 process, a pathway to the second computer 120, and a socket on the second computer 
^ 120. The destination information could be any information indicative of the destination 

C3 122. Some examples of the destination information are a process name, a pathway name, 

f ^ an Internet Protocol address, and a port number. 

*3 A message is any information or data to be communicated between the first 

20 computer 110 and the second computer 120. The message information could be any 

information indicative of the message. In some embodiments, the message information is 
the message itself. Some examples of the message information are a pointer to the 
message and the length of the message. The message object 114 could be any object used 
to transmit the message information to the destination. Objects are modules that contain 
25 data and instructions. Objects are the building blocks in object oriented programming. 
The transport protocol could be any protocol for transmitting the message 
information to the destination 122 using the message object 1 14. Some examples of the 
transport protocols are process to process communication, process to pathway 
communication, and process to socket communication. Dynamically determining the 
30 transport protocol at run-time allows the transport protocol to be determined by an 

environment variable. This allows the system administrator to alter the transport without 
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recompiling or modifying code. Also, new transport protocols can be added without 
recompiling or modifying code. The system administrator may have to relink a new 
transport into programs. 

FIG. 2 depicts a flow chart of the communication system 100 in an example of the 
5 invention. FIG. 2 begins in step 200. In step 202, the first computer 1 10 receives 

destination information indicative of the destination 122 from the first process 1 12. In 
step 204, the first computer 110 determines the transport protocol for the message object 
1 14 based on the destination information. In step 206, the first computer 110 then 
generates a message object 114 based on the destination information. In step 208, the first 
^10 computer 110 receives message information indicative of a message to be transmitted 

s "s 

%3 from the first process 1 12 to the destination 122. The first computer 110 transmits the 
V n message information from the first process 1 12 to the destination 122 using the message 

TITS' 

^ object 1 14 and the determined transport protocol in step 210. FIG. 2 ends in step 212. 

as:. 
5 5 3 
■ar » 

15 Dynamic Inter-Networked Guardian User's Service (DINGUS^) Framework - FIG. 3-11 

3 

H FIGS. 3-11 disclose one embodiment of the invention, but the invention is not 

q restricted to the configuration provided below. Those skilled in the art will appreciate 
*L? numerous variations in a communication system configuration and operation that are 
S3 within the scope of the invention. Those skilled in the art will also appreciate how the 
20 principles illustrated in this example can be used in other examples of the invention. A 

particular reference number in one figure refers to the same element in all of the other 

figures. 

This embodiment is a framework which is written in C++ for Tandem's Guardian 
environment. This embodiment provides a standard communications interface for 
25 software development on the Tandem. The DINGUS framework comprises a Message 
class, an Application class, a Service class, and a Transport class. The Message class is 
discussed below in FIG. 8. The Application class and the Service class are discussed 
below in FIG. 9. The Transport class is discussed below in FIG. 10. 
Process to Process 

30 FIGS. 3-5 show an example of process to process communication in an example 

of the invention. FIG. 3 depicts a block diagram of a communication system 300 in 
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process to process communication in an example of the invention. The communication 
system 300 comprises a first computer 310 and a second computer 320. The first 
computer 310 comprises a first process 312 and a message object 314. The second 
computer 320 comprises a second process 322. The message object 314 is logically 
5 connected to the first process 312 and the second process 322. 

FIG. 4 depicts a flow chart for the communication system for process to process 
communication for transmitting a message in an example of the invention. FIG. 4 begins 
in step 400. This embodiment includes three message classes for I/O communication: 
Message, MessageSHELL, and MessageSDP. The Message class allows for 
1 0 communication to other computers running the DINGUS framework. The 

u 

h.g MessageSHELL class allows communication with a computer running the RMS shell. 
^ MessageSDP class provides communication to external systems through TEC, VECTOR, 
=P MQ, or CORBA. The Message SDP class formats message data to be used in conjunction 
jn with the SDP hublets. 

^ 1 5 FIG. 4 illustrates usage of the Message class. One constructor for the Message 

H class is shown as: 

□ 

q Message (char *server, char *request, int reply_length); 

^ In order to create an instance of the Message class, the above constructor is specified with 
£3 three parameters: the name of the server to communicate with, the name of the service to 
20 call, and the maximum reply length tolerated. In this embodiment, the name of the 
service is case sensitive and can not be more than 27 characters in length (28 if the 
terminating zero is counted). For unsupported message formats, the service name is 
"NULL" in the Message constructor, which transmits an unformatted message. If the 
message sent by the "post" method discussed below is formatted, then the 
25 communication can occur with another communication. 

In step 402, the first computer 310 receives destination information indicative of 
the second process 322 from the first process 312. In this embodiment, the destination 
information is the name of the server to communicate with and the name of the service to 
call. In step 404, the first computer 310 determines the transport protocol for the message 
30 object 314 based on the destination information. In this embodiment, the determined 
transport protocol is process to process. In step 406, the first computer 310 generates a 
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message object 314 based on the Message constructor by specifying the name of the 
server to communicate with, the name of the service to call, and the maximum reply 
length tolerated. In step 408, the first computer 310 receives message information 
indicative of a message to be transmitted from the first process 312 to the second process 
322. In this embodiment, the message information is a pointer to the message and a 
length of the message. 

The first computer 310 may transmit messages to the second computer 320 by a 
waited message or a nowait message. When sending a waited message, all processing is 
halted until the reply to the message is received. Waited messages may also be known as 
synchronous or blocking messages. With nowait messages, the first computer 310 
performs other tasks such as SQL work or other messaging while waiting for the reply 
from the second computer 320. 

In step 410, the first computer 310 transmits the message information for a waited 
message from the first process 312 to the second process 322 using the message object 
314. The first computer 310 calls a "post" method of the message object 314. The "post" 
method accepts two parameters: the pointer to the waited message and the length of the 
message. An example of the "post" method is shown as: 

char buf[] = "this is an example message"; 

ms.post (buf, strlen(buf)+l); 

For error checking, the first computer 310 checks for a Message error returned by 
the "post" method. The errors returned by the "post" method are system errors. One 
example is of error checking for the "post" method is shown as: 

int error; 

error = ms.post(data, length); 
if (error) { 

cout « "Post failed due to file error: " « error « endl ; 

} 

For advanced error handling, the first computer 310 uses an additional parameter 
in the Message constructor called the error service. This error service is an instance of a 
user defined service class which is called if a posted message should encounter an error. 
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The first computer 310 generates a unique identifier, a tag, for every message 
posted. The "getTag" method of the Message class returns this value. The tag is useful in 
associating the message posted with the message replied. One example of using the 
"getTag" method is shown as: 

long global_tag; 

ms0.post(dataO, lengthO); 
msl.post(datal, lengthl); 
global_tag = msl.getTagO; 

void ReplyHandler::execute(Message &ms) { 
if (ms.getTagO = = global_tag) 

cout « "this is the reply to ml" « end 1; 

else 

cout«"this must be the reply to mO" endl ; 

} 

These tags are used to locate messages. Inbound messages are stored in a vector 
named "inbound" which is a static public data member of the Message class. All 
outbound messages are stored in a vector named "outbound". These two vectors provide 
freedom to maintain complicated nowait messaging schemes. 

In step 412, the first computer 310 then receives a reply from the second process 
322. The first computer 310 receives the reply using two methods: getBuffer and 
getBufferlength. The getBuffer method returns a pointer within the message object 314. 
The getBufferlength method returns the length of the reply. FIG. 4 ends in step 414. 

For nowait messages, the first computer 310 uses the constructor below: 

Message (string server, string request, int size, Service *reply). 
The constructor is similar to the constructor for the waited messages except for the last 
parameter, reply service. The reply service is a service to be called when the reply to the 
message "post" is returned. 

FIG. 5 depicts a flow chart for the communication system 300 for process to 
process communication for receiving a message in an example of the invention. FIG. 5 
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%SA 8 



begins in step 500. FIG. 5 uses two different classes: a Service class and an Application 
class. Both the Service class and the Application class are generic base classes from 
which other more complicated and useful classes can be derived. The Application class 
provides a framework from which an entire application is built. The Application class 
5 provides for listening of incoming messages and determines which services to execute. 
The Service class provides a framework from which individual services are built. Both 
the Service class and the Application class are discussed below in FIG. 9. 

In step 502, the first computer 310 registers a service to enable calling from 
another process. In the Service class, the registerService method registers a unique name. 
10 In this embodiment, the name of the service is 27 characters or less. One example of the 
registerService method is shown as: 
CharacterHandler chandler; 
chandler.registerService ('CharacterHandler"); 
i If a request for a registered service comes in an unrecognizable format, a default 

^15 request service can be specified. In this embodiment, a service with no name is registered 
a for a default request service. One example of a default request service is shown as: 
class UnknownHandler: public Service { 
public: 

Unknownhandler () { 
20 registerService (NULL); 

} 

void execute (Message &ms) { 

cout « "unknown request" « endl ; 
ms.reply (NULL, 0); 

25 } 

}; 

In step 504, the first computer 310 performs an "execute" method from the 
Service class. The "execute" method accepts the message object as a parameter for 
extraction, manipulation or replying back to the message object. The "execute" method 
30 performs no operations. However, the "execute" method is intended to be overridden by a 
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developer. The developer can create a new class from the Service class and override the 
"execute" method. One example of the "execute" method is shown as: 
class CharacterHandler: public Service { 
void execute(Message &msg); 

}; 

In step 506, the first computer 310 performs a "reply" method from the Message 
class. The "reply" method, which is similar to the "post" method, receives a message by 
accepting two parameters: a pointer to the message and the length of the message. One 
example of the "reply" method is shown as: 

void CharacterHandler:: execute (Message &ms) { 
char *buf; 

buf = (char *)malloc(ms.getLength()+4); 
sprintf("«%s»", ms.getbuffer()); 
ms.reply(buf, strlen(buf)+l); 
free(buf); 

} 

For error checking, the first computer 310 checks for a Message error returned by 
the "reply" method. One example of error checking for the "reply" method is shown as: 
int error; 

error = ms.reply(data, length); 
if (error) { 

cout « "Reply failed due to file error: " « error « endl; 

} 

In step 508, the first computer 310 performs a "listen" method from the 
Application class. The "listen" method provides a dispatch loop for a process. One 
example of the "listen" method is: 
void main(void) { 

Application app; 
app.listenQ; 
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} 

For error checking, the first computer 310 checks for a Message error returned by 
the "listen" method. As long as there are either timers, registered services, or nowait 
replies expected, the "listen" method will continue to run until there is nothing left to do, 
or some sort of critical error is encountered that prevents it from operating. One example 
is of error checking for the "listen" method is shown as: 
int main(void) { 
int error; 
Application app; 

error = app.listen(); 
if (error) 

cout « "critical listen error: " « error; 
return error; 

} 

Another Message class is MessageTIMER. MessageTIMER behaves similar to a 
regular message except that the message never actually goes anywhere. The reply service 
is called after a specified length of time. The constructor for a MessageTIMER accepts a 
reply service and a length of time measured in centiseconds. In this embodiment, macros 
convert DAYS, HOURS, MINUTES into centiseconds. One example of the 
MessageTIMER is shown as: 

MessageTIMER mt(MINUTES(5), reply); 

mt.post (data, length); 

class TimerHandlenpublic Service { 
public: 

void execute(Message mt) { 
charbuf[80]' 
static int count = 0; 
cout « mt.getBufferO « endl ; 
if(count<5) { 
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count-H-; 



sprintf(buf, 'this is timer %1, count); 
mt.post (buf, strlen(buf)+l); 



} 



} 



}; 



Process to Pathway 

FIG. 6 shows an example of process to pathway communication in an example of 
the invention. FIG. 6 depicts a block diagram of a communication system 600 in process 
to pathway communication in an example of the invention. The communication system 
600 comprises a first computer 610 and a second computer 620. The first computer 610 
comprises a first process 612 and a message object 614. The message object 614 is 
logically connected to the first process 312 and a pathway 622. The pathway 622 is also 
connected to the second computer 620. 

The operation of the process to pathway communication is similar to the operation 
of the process to process communication discussed above. One difference is that in the 
Message constructor, a SHELL style pathway name is specified. The pathway name 
comprises a pathmon and the server. In this embodiment, the pathmon name begins with 
the "#" symbol followed by a " A " symbol and then the server name. 
Process to Socket 

FIG. 7 shows an example of process to socket communication in an example of 
the invention. FIG. 7 depicts a block diagram of a communication system 700 in process 
to socket communication in an example of the invention. The communication system 700 
comprises a first computer 710 and a second computer 720. The first computer 710 
comprises a first process 712 and a message object 714. The second computer 720 
comprises a socket 722. The message object 714 is logically connected to the first 
process 712 and the socket 722. 

The operation of the process to pathway communication is similar to the operation 
of the process to process communication discussed above. One difference is in the 
Message constructor an Internet Protocol address and a port number of the socket are 
specified. One example is shown as: 
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144.223.107.23:1066 

Also, the "listen" method described above can listen on TCP/IP socket ports. The 
port number is specified in the "listenOn" method of the Application class. One example 
of the "listenOn" method is shown as 
5 int main(void) { 

int error; 
Application app; 

error = app.listenOn ("127.0.0.1 :1066"); 
10 if (error) 

cout « "port unavailable:" « error « endl; 
error app.listen(); 

} 

FIG. 8 depicts a block diagram of the Message class in an example of the 
KM 5 invention. A Message class 810 is connected to a Message constructor 812, a post method 
u 814, a reply method 816, an abort method 818, a create method 820, a commit method 
822, a status method 824, a getBuffer method 826, a getBufferLength method 828, a 
getHeader method 830, a getHeaderlength method 832, a getTag method 834, a 
getSystemTag method 836, a getError method 838, a getServername method 840, a 
20 getServiceName 842, a getReplyService method 844, a getErrorService method 846, a 
getTimelimit method 848, a « operator 850, a » operator 852, a parent method 854, 
and a children method 856. 

The Message class 810 provides a method for formatting messages to be sent to a 
destination. Besides the Message base class, several other derived classes are included to 
25 handle various message formats. 

The Message constructor 812 is shown as: 
Message (const char* server = NULL, 
const char* service = NULL, 
unsigned int size = 0, 
30 Service* reply = NULL, 

Service* error = NULL, 
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unsigned long timelimit = 0); 

where the server parameter is a special character representation of the destination 
server; the service parameter is a character string representation of the destination 
service; the size parameter is the maximum number of expected bytes for the reply; the 
reply parameter is a service for nowait messages; the error parameter is called if an error 
is detected; and the timelimit parameter is the length of time a message remains active 
before the error service is called. The operation of the Message constructor 812 is 
discussed in further detail above. 

The post method 814 is shown as: 

void post (const void *buffer = NULL, unsigned int length = 0); 

where the buffer parameter is a pointer to an address in memory to be transmitted; 
and the length parameter is the number of bytes to be transmitted. The operation of the 
post method 814 is discussed in further detail above. 

The reply method 816 is shown as: 

void reply (const void *buffer = NULL, unsigned int length = 0); 

where the buffer parameter is a pointer to an address in memory to be received; 
and the length parameter is the number of bytes to be received. The operation of the reply 
method 816 is discussed in further detail above. 

The abort method 818 rolls back TMF and sends reply data back to the porting 
server's error service. The abort method 818 is shown as: 

void abort (const void *buffer = NULL, unsigned int length = 0); 

where the buffer parameter is a pointer to an address in memory to be transmitted; 
and the length parameter is the number of bytes to be transmitted. 

The create method 820 manually creates a TMF bracket to be associated with the 
Message object. The create method 820 is shown as: 

void create(void). 

The commit method 822 manually commits the TMF bracket associated with the 
Message Object. Since committing a TMF bracket is a nowait operation, a callback 
service must be provided if notification is required. The commit method 822 is shown as: 

void commit (Service *callback = NULL). 
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The status method 824 returns the current TMF status of the Message. The status 
method 824 is shown as: 
int status (void). 

The status code includes internal error (-1), nil state (0), active (1), prepared (2), 
5 committed (3), aborting (4), aborted (5), and hung (6). 

The getBuffer method 826 returns a pointer to the message buffer. The getBuffer 
method 826 is shown as: 

Const char* getBuffer(void) const; 

The getBufferlength method 828 returns the number of bytes contained within a 
1 0 message buffer. The getBufferlength method 828 is shown as: 
^ unsigned int getBufferLength(void) const. 

Cm The getHeader method 830 returns a pointer to the message header. The 

M 

lz getHeader method 830 is shown as: 

f ~: const char* getHeader(void) const. 

C0 1 5 The getHeaderLength method 832 returns the number of bytes contained within a 

Li message header. The getHeaderLength method 832 is shown as: 
J~ unsigned int getHeaderLength(void) const. 

Cn The getTag method 834 identifies a unique tag number of a message object after a 

f 5 "post" method. The unique tag number is helpful in identifying a particular message. The 
20 getTag method 834 is shown as: 
long getTag(void) const; 

The getSystemTag method 836 returns the value of a system tag number defined 
by the operating system for inbound messages. The system tag number is useful in 
determining information about the message. The getSystemTag method 836 is shown as: 
25 short getSystemTag(void) const; 

The getError method 838 returns the error number of the last operation 
performed. The getError method 838 is shown as: 

int getError(void) const; 

The getServerName method 840 returns the "server" parameter supplied in the 
30 message constructor. The getServerName method 840 is shown as: 
const char* getServerName(void) const; 
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The getServiceName method 842 returns the "service" parameter supplied in the 
message constructor. The getServiceName method 842 is shown as: 
const char* getServiceName (void) const; 

The getReplyService method 844 returns the "reply" parameter supplied in the 
message constructor. The getReplyService method 844 is shown as: 
Service* getReplyService(void) const; 

The getErrorService method 846 returns the "error" parameter supplied in the 
message constructor. The getErrorService method 846 is shown as: 
Service* getErrorService(void) const; 

The getTimelimit method 848 returns the "timelimit" parameter supplied in the 
message constructor. The getTimelimit method 848 is shown as: 
Unsigned long getTimelimit 0 const; 

The « operator 850 copies the recognized object into the message buffer and 
calls either the "post" method or the "reply" method. Calling the « operator 850 on an 
RWCollectable object calls the "saveGuts" method. The « operator 850 is shown as: 

void operator « (const RWCollectable& object); 

void operator « (const char* object); 

Although there is no "«" equivalent to the abort method, the following shows 
the possibility of aborting a message and replying back at the same time: 
msg.abort(); 
msg « object; 

The » operator 852 copies the buffer data into the recognized object. Calling the 
» operator 852 on a RWCollectable object calls the "restoreGuts" method. Calling the 
» operator 854 on a char* calls the "strcpy" function. The » operator 852 is shown as: 

void operator » (RWCollectable &object) const; 

void operator » (char *object) const; 

The parent 854 points to the inbound message for any outbound message object 
posted from within a request service. Using parent 854 helps to associate an outbound 
message with the inbound message that triggered its creation. If an inbound message has 
no associated outbound messages, the parent 854 points to 6C NULL". An example of the 
parent 854 is shown as: 
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void ExampleRequestService::execute (Message &inbound) { 
outbound.post(ptr,length) 

} 

void ExampleReplyService::execute (Message &outbound) { 
outbound.parent~>reply (outbound.getBuffer(), outbound.getBufferLenthO); 

} 

The child 856 contains a list of all associated outbound messages if an inbound 
message object is a parent 854. Once an outbound message has been replied to, the 
outbound message is removed from the list of children 856. The child 856 is shown as: 

Roster<Message> children; 

One example of the child 856 is shown as 

Void ExampleReplyService::execute (Message &out) { 

if (out.parent->children.lengthO = 0) { 
out.parent->reply (ptr, len); 

} 

} 

FIG. 9 depicts a block diagram of a Service class 910 and an Application class 
920 in an example of the invention. The Service class 910 is connected to an execute 
method 912 and a registerService method 914. The Application class 920 is connected to 
a listen method 922, a listenOn method 924, a exitListen method 926, and an awaitiox 
method 928. 

The Service class 910 is a generic base class meant to be used to derive more 
powerful services. The execute method 912 is intended to be overridden by the user. The 
user places application logic within the execute method 912. The execute method 912 is 
shown as: 

virtual void execute(Message &msg); 
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The "msg" parameter is a reference to either an inbound or outbound message 
object depending upon the situation. Registered services reference inbound messages. 
Reply or error services reference outbound messages. 

The registerService method 914 allows a registered service to be called by 
5 external processes. Reply or error services are not registered. The registerService method 
914 is shown as: 

virtual void registerService (const char *name = NULL), 
unsigned int value = tmf::propagate | reply: :late); 
The "name" parameter matches the "service" parameter of the Message 
1 0 constructor exactly. In this embodiment, the name parameter is limited to 27 characters. 
If the service is registered with no name, a default request service is created. All 
unformatted messages are directed to this default request service. Services with multiple 
names may be registered, but multiple services may not be registered with the same 
name. One example of the value parameter is shown as: 
1 5 class tmf { 

public: 

enum { none = 0x00, 

propagate =0x01, 
create = 0x02, 

20 automatic =0x03}; 

}; 

class reply { 
public: 

enum { late =0x00, 
25 early =0x04}; 

}; 

The Application class 920 performs all of the message routing tasks. The 
Application class 920 performs initialization. The listen method 922 is a loop that listens 
for inbound messages and replies to outbound messages and directs the messages to the 
30 proper service. The listen method 922 returns successfully if there are no registered 

services and there are no pending outbound messages. The listen method 922 returns with 
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an error code on any recoverable error. Because the listen method 922 is a loop, the listen 
method 922 should not be placed within another loop. Calling the listen method 922 
again after the listen method 922 has terminated does not yield any new results. The 
listen method 922 is shown as: 
5 int listen(void); 

The listenOn method 924 allows users to listen on any supported transport. The 
listenOn method 924 is shown as: 

int listenOn (char *server); 

The server parameter is a character string representing the protocol used to listen 
1 0 for incoming messages. Listening on "$receive" happens automatically upon instantiating 
an Application object. 



[=1 

j a The exitListen method 926 allows the user to terminate the listen method. The 



s H exitListen method 926 is shown as: 
m static void exitListen(int error); 

1 5 The awaitiox method 928 is intended to be overridden by the user. If the listen 

H' loop encounters an unknown signal, the awaitiox method 928 is called to be handled by 

G 

q the user. All of the parameters found within the awaitiox method 928 correspond to the 
J:: Guardian procedure called "awaitiox". The awaitiox method 928 is shown as: 
13 virtual void awaitiox ( _cc_status cc_error, 

20 short filenum, 

long *buffer, 

short count, 

long tag, 

short segmented); 

25 The cc_error parameter is the value returned by the awaitiox function from within 

the listen loop. The filenum parameter represents the file number of the I/O event. The 
buffer parameter is a pointer to memory containing data written during the I/O event. The 
tag parameter is the same tag value used by the function that initiated the I/O event. The 
segmented parameter represents the memory segment reference by the I/O event. 

30 FIG. 10 depicts a block diagram of a Transport class 1010 in an example of the 

invention. The Transport class 1010 is connected a registered data member 1012, a clone 
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method 1014, a close method 1016, an open method 1018, a post method 1020, a reply 
method 1022, a listen method 1024, a cancel method 1026, an inspect method 1028, an 
accept method 1030, a registerTransport method 1032, and an assignTransport method 
1034. The Transport class 1010 provides methods for sending and receiving messages 
5 from other processes. Process to process, process to pathway, process to socket transport 
protocols are supplied, but other transport protocols may be added. Registering a tranport 
makes it available to be used by the Message class. 

The registered data member 1012 is a list that contains an instance of each derived 
Transport class available for use. The clone method 1013 calls the copy constructor. The 
1 0 close method 1016 closes the derived transport mechanism. The open method 1018 opens 

*3 the derived transport mechanism. The post method 1020 sends data through the derived 

Iq transport mechanism. The reply method 1022 sends data back through the derived 
transport mechanism. The listen method 1024 reads data from the derived transport 

yl mechanism. The cancel method 1026 provides a way of cancelling an outstanding 

l~ 1 5 message. 

Ji; The inspect method 1028 completes the call to listen. The inspect method 1028 

13 performs any clean up activities required after reading data from the derived transport 
7^ mechanism. The accept method 1030 returns true if the server name of the message 
^3 object matches the derived transport's naming convention. The registerTransport method 
20 1032 places a transport object onto the registered linked list. The assignTransport method 
1034 accepts a server name and searches the registered list for a transport object that will 
accept. If a match is found, the clone method 1014 is called and a copy of that object is 
returned. The assignTransport method 1034 allows message objects to obtain a fresh 
transport dynamically without knowing the actual transport mechanism to be used. 
25 The Transport class 1010 also comprises the TransportProcess class, the 

TransportPathmon class, and the TransportSocket class in FIG. 1 1 . FIG. 1 1 depicts a 
block diagram of a TransportProcess class 1 1 10, a TransportPathmon class 1130, and a 
TransportSocket class 1 140 in an example of the invention. The Transport class 1 1 10 is 
connected to an open method 1 1 12, a close method 1 1 14, a post method 1 1 16, a reply 
30 method 1 1 18, a listen method 1 120, a cancel method 1 124, and an accept method 1 126. 
The TransportPathmon class 1 130 is connected to a post method 1 1 32 and an accept 
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method 1 134. The TransportSocket class 1 140 is connected to an open method 1 142, a 
close method 1 144, a post method 1 146, a reply method 1 148, an inspect method 1 150, 
and an accept method 1 1 52. 

The TransportProcess class 1010 provides the read/write functionality for process 
5 to process communication. The open method 1112 calls FILE_OPEN_. The close method 
1 1 14 calls FILE_CLOSE_. The post method 1116 calls WRITEREADX. The reply 
method 1118 calls REPLYX. The listen method 1 120 calls READUPDATEX. The 
cancel method 1 122 call CANCELREQ. The inspect method 1 124 determines the system 
message tag. The accept method 1 126 returns true if the server name fits the Guardian 
f «k 1 0 process name syntax. 

^=f The TransportPathmon class 1 130 provides write functionality for Pathway 

m communication. The post method 1 132 call SERVERCLASSJSEND_. The accept 
Tl method 1 134 returns true if a server name contains a "#" symbol followed by a pathmon 
CP name, followed by a " A " symbol, followed by a server-class name. 

?r« 

„ " 1 5 The TransportSocket class 1 140 provides read/write functionality for TCP/IP 

II sockets. The open method 1 142 calls connectjiw for postable messages. The open 

S3 method 1 142 call bind_nw, listen, for readable messages. The close method 1 144 call 

m 

FILE_CLOSE_. The post method 1 146 calls sendjnw followed by recv_nw. The reply 
lJ method 1 148 calls sendjnw. The inspect method 1 150 sets the message service name to 
20 either TCP/IP spawn if the server is to spawn a new process, or 

"CompleteSocketConnection" if it is not. The accept method 1 152 returns true if the 
server name is an IP address followed by a ":" and a port number. 

By dynamically determining the transport protocol at run-time, the transport 
protocol may be determined by an environment variable. This allows the system 
25 administrator to alter the transport without recompiling or modifying code. The developer 
can also add transport protocols or message objects. 

Another advantage is multiple messages formats in a standardized way with the 
actual data format hidden from the user. The developer writes a single piece of code 
capable of interacting with multiple server using different message formats and transport 
30 protocols. 
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Another advantage is the handling of both waited and nowait messages. With the 
option of wait or nowait messages, the developer then can write more powerful and 
efficient applications. 

Error services is another advantage which allows developers to distinguish error 
5 conditions and separate error handling logic from normal business logic. The ability to 
invoke error services is considered as exception handling across processes. Error 
notification allows the developer to either retry the offending logic or propagate the error 
further upstream. 

Automatically associating each incoming TMF bracket with all outgoing 

1 0 messages within a logical thread allows developers to rollback database work in the event 
of an error within a process or across processes. 

Another advantage of this embodiment is the code is written in C++, a high level 
programming language. This provides a standard communications interface for software 
development on the Tandem computers. Those skilled in the art understand the benefits 

1 5 of object oriented programming languages such as maintenance and the ease of using 
objects to build applications. The code is also Native Mode compatible. The DINGUS 
framework reduces the complexity required to write multi-threaded applications in a 
Tandem environment. The ease of use of the DINGUS framework and the object oriented 
programming reduces the time to build applications. The DINGUS framework also 

20 abstracts the platform specific messaging of the Tandem machine, so non-Tandem 
programmers can build applications in the Tandem environment. 

The above-described elements can be comprised of instructions that are stored on 
storage media. The instructions can be retrieved and executed by a processor. Some 
examples of instructions are software, program code, and firmware. Some examples of 

25 storage media are memory devices, tape, disks, integrated circuits, and servers. The 
instructions are operational when executed by the processor to direct the processor to 
operate in accord with the invention. Those skilled in the art are familiar with 
instructions, processor, and storage media. 

Those skilled in the art will appreciate variations of the above-described 

30 embodiments that fall within the scope of the invention. As a result, the invention is not 
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